1. Technical Field
This invention relates to a system, method and apparatus for direct execution of an architecture-independent binary program directly on a computer. More particularly, the invention relates to a system, method and apparatus permitting a user to invoke an architecture-independent binary program without identifying an interpreter program used to interpret the architecture-independent program and without specifying any libraries needed to resolve run-time program calls.
2. Background of the Invention
Generally, computer programs are stored in one of two forms. In one form, the program is stored as a text file (source code) consisting of of human-readable statements using an encoding of letters, digits and other printable characters in a character code such as American Standard Code for Information Interchange (ASCII) or Extended Binary Coded Decimal Interchange Code (EBCDIC). Such programs are not directly executable by a computer, and in order to be executed, must be interpreted by a special purpose program, called an interpreter, written to understand the language in which the program is written. A typical example is a program written in Beginner's All-purpose Symbolic Instuction Code (BASIC). BASIC programs are typically presented to an interpreter in source form, and interpreted line-by-line.
In another form, a source code file is processed by a compiler to produce an object file. The object file includes a sequence of binary data (object code) that are meaningful only to a specific computer architecture, in that the data represents a sequence of instructions for that particular architecture. The object file may be loaded into the computer's storage and the instructions directly executed by the computer by instructing the computer to fetch and execute the instructions from the location at which the program is loaded, without the need for an interpreter. Alternatively, the object file may be used by a linker as input to create a file that includes executable program code from several such object files. Using the BASIC example, a BASIC source file may be compiled to produce an object file that is directly executable on a target computer.
A disadvantage to this approach is that such a program is not portable. Because the binary code is machine-specific, the program cannot be easily ported to a computer system of a different architecture. This makes the use of purely binary programs unattractive in a heterogeneous environment.
One approach has been to provide computer programs in a human-readable text format, rather than in binary format. An interpreter is invoked to read the text program (often called a "script" to distinguish it from a binary program) and to interpret the statements in the program, executing them one at a time. This is effectively the first approach of using an interpreted BASIC program. A disadvantage to this approach is that there is significant overhead in interpreting the text statements. For example, the interpreter must devote significant computing resources to lexical scanning and validation of each statement, to assure that it represents a syntactically correct and executable operation. This resource intensity makes the use of scripts unattractive.
Sun.TM. Microsystems has produced a solution known as Java..TM. Java.TM. is designed to meet the challenges of application development in the context of heterogeneous, network-wide distributed environments. The challenges include the secure delivery of applications that consume the minimum of system resources, can run on any hardware and software platform, and can be extended dynamically. The requirement to operate on multiple platforms in heterogeneous networks invalidates the traditional schemes of binary distribution, release, upgrade, patch, and so on. Instead, the Java.TM. system provides an architecture-neutral, portable, and dynamically adaptable quasi-machine code binary format.
A remaining difficulty with this format, however, is that the user is required to know whether a program he or she desires to run is written in Java.TM. or is encoded as a native binary program appropriate for his computing platform. If encoded in the native format, the program is directly executable. If encoded as a Java.TM. class file, the user must invoke the Java.TM. interpreter to interpret the bytecodes in the file.
It is therefore desirable to provide a method of encoding a Java.TM. class file in a format that is consistent with the computing platform on which the program is to be executed. It is further desirable to encode the file in a format that is an industry standard and that is amenable to implementation on a wide variety of computing platforms, thereby ensuring that the file remains portable across such platforms. It is further desirable to provide support in the format for identifying the locations of program files external to the executed file, in order to allow the dynamic resolution of those external files at runtime.